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ABSTRACT 

Teleoperated robots require one or more humans to 
control actuators, mechanisms, and other robot 
equipment given feedback from onboard sensors. To 
accomplish this task, the human or humans require 
some form of control station. Desirable features of 
such a control station include operation by a single 
human, comfort, and natural human interfaces 
(visual, audio, motion, tactile, etc.). These interfaces 
should work to maximize performance of the 
human/robot system by streamlining the link between 
human brain and robot equipment. 

This paper describes development of a control station 
testbed with the characteristics described above. 
Initially, this testbed will be used to control two 
teleoperated robots . Features of the robots include 
anthropomorphic mechanisms, slaving to the testbed, 
and delivery of sensory feedback to the testbed. The 
testbed will make use of technologies such as helmet 
mounted displays, voice recognition, and 
exoskeleton masters. It will allow for integration and 
testing of emerging telepresence technologies along 
with techniques for coping with control link time 
delays. 

Systems developed from this testbed could be 
applied to ground control of space based robots. 
During man-tended operations, the Space Station 
Freedom may benefit from ground control of IVA or 


EVA robots with science or maintenance tasks. 
Planetary exploration may also find advanced 
teleoperation systems to be very useful. 

1.0 INTRODUCTION 

Remotely controlled robots may be successfully 
applied in hazardous environments such as high 
radiation zones, deep sea locations, earth orbit, and 
extra-terrestrial sites. Three dominant control modes 
are teleoperation, supervised autonomy, and shared 
control 1 . Teleoperation is characterized by direct 
human-in-the-loop manual control and small time 
delays (< 1 sec.). In supervised autonomy, 
commands are generated by the operator and sent to 
the robot control system for execution. Shared 
control makes use of both teleoperation inputs and 
an autonomous robot control system. In each of 
these modes, a human operator is involved and must 
interact with some form of computer based control 
station. 

Figure 1.1 illustrates a spectrum of technologies 
which may be used in a remote robot control station. 
At one end are conventional technologies such as 
hand controllers, 2-D video, keyboards, and computer 
monitors. The other end is labeled as telepresence 
technologies and includes force reflective 
exoskeletons, stereo (3-D) video, voice recognition, 
and synthetic speech. 



Figure 1.1 - Remote Robot Control Technology Spectrum 
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Telepresence can be defined as the sense of being 
physically present with object(s) at a remote site^. 
Telepresence technologies attempt to immerse a 
human operator in the remote environment with 
actuator control and sensory feedback devices which 
closely interface to the human central nervous 
system. Robots at the remote site are designed with 
anthropomorphic actuators and sensory devices, 
such as stereo camera pairs and tactile sensors. 

Telepresence technologies offer interfaces to the 
human sensory system which are more direct than 
those of the conventional technologies defined. This 
frees the brain from many unnatural input/output 
conversion tasks, allowing more concentration on 
higher level control and process oriented tasks. The 
result is a more intuitive way of controlling remote 
robots. 

Major challenges facing telepresence technologies 
include working with time delays, increasing video 
resolution and field of view, and provision of adequate 
forceAorque and haptic feedback. 

2.0 PROJECT OVERVIEW 

2.1 Objectives 

The primary project objective is to develop a 
teleoperator control station testbed which makes use 
of telepresence technologies. This testbed is 
referred to as the Teleoperated Robot Interface 
Platform (TRIP) and should provide teleoperation 
capabilities for two JSC development robots. One 
robot is the Dexterous Anthropomorphic Robotic 
Testbed (DART) 4 . DART is a dual-arm, dual-hand 
robot with a camera platform which provides stereo 
video. It will be able to operate under human control 
augmented by on board intelligence for use in 
development of IVA and EVA robotic systems. The 
second, AERCAM, is a prototype mobile camera 
platform capable of teleoperation. Initially, this 
prototype will be flown on an air bearing floor at JSC. 

In a more general sense, TRIP will be used as a 
testbed for emerging telepresence technologies, 
such as head mounted displays, exoskeletons, and 
programming systems. In addition, TRIP will allow 
testing of proposed solutions to the problems induced 
by control link time delays. Systems developed with 
the TRIP testbed should support future operations on 
board the Space Station Freedom, including the 
possibility of ground control using shared control 
techniques. 


2.2 Goals & Constraints 

TRIP development goals include flexibility, ease of 
use, and growth paths. A flexible system will support 
the testbed objectives through maximum use of 
standard hardware and software interfaces, a 
modular approach to system design, and the use of 
software for most calibration tasks. The system 


should also allow for ease of development and use by 
minimizing and simplifying the software learning 
curves. Ease of use will support tight schedules and 
minimal manpower. A system designed with growth 
paths will foster an evolutionary development by 
protecting both hardware and software investments. 
Design for growth seeks to avoid obsolescence by 
choosing established software tools with supported 
growth paths and by avoiding hardware with closed or 
unsupported architectures. 

Development constraints consist of cost and system 
performance. Design must be sensitive to costs by 
maximizing system capability given current year 
funding. Basic system level results should not 
depend on large amounts of future funding. Basic 
performance requirements, such as data rates and 
connectivity, must also be satisfied. Optimization of 
performance variables at the expense of system 
flexibility will be avoided unless required. 

2.3 Facilities & Support 

TRIP is under development in the Dexterous Robotics 
Lab of JSC's Automation & Robotics Division. The 
two target robots are also under development in 
division labs. To date, all primary design and 
development work has been conducted in-house by 
JSC civil service staff members. Only a limited 
amount of contractor support has been available or 
used. 
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Figure 3.1.1 

• TRIP Subsystems and Technologies 


3.0 SYSTEM DESCRIPTION 


3.1 Organization 

TRIP is the integration of assorted telepresence 
technologies as illustrated in figure 3.1.1. These 
include exosketetons for the operators hand, wrist 
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and arm joints, a head mounted display for viewing 
stereo video and graphics, speech synthesis and 
voice recognition systems, and a network interface 
for passing data to/from a remote robot. These 
systems should work in concert to provide intuitive 
control of a remote robot by one human operator. 
TRIP is organized into five subsystems, each 
consisting of hardware and associated software. 

3.2 Hardware Architecture 

The hardware architecture is shown in figure 3.2.1. 
Selections were driven primarily by the flexibility goal 
along with the availability and cost of both software 
and special purpose boards (video, audio, etc.). 
Hardware cost and growth path trends were also 
considered. 



Figure 3.2.1 - Hardware Architecture 

The hardware architecture consists of exoskeletons, 
a head mounted display, a chair platform with control 
pedals, i486 & i386 microprocessors in ISA & VME 
buses, and assorted I/O, audio, and video boards. A 
single family of processors was selected to minimize 
software learning curves and keep costs relatively 
low. The ISA bus offers reasonable performance and 
a myriad of low cost, special purpose I/O boards to 
choose from. The VMEbus offers an industry 
standard with high bandwidth performance, extreme 
flexibility, and a large number of I/O and processor 
boards. Selections of boards for both buses were 
based on a balance of cost, flexibility, and 
performance. Software driver libraries were also 
considered in the board selections as this represents 


a potentially labor intensive set of development 
tasks. 

Exoskeletons are attached to a body harness and 
gloves which the operator wears. An analog signal 
conditioning box provides power to the exoskeletons 
and filters the signals produced by potentiometers 
and hall effect sensors. These signals are then read 
by an analog to digital (A/D) converter board in the 
VMEbus. An embedded i386 computer processes raw 
data from the A/D board and makes the results 
available on the VMEbus. 

The head mounted display (HMD) consists of 
monitors, optics, a position sensor, headphones, and 
a microphone. The position sensor reports roll, pitch, 
and yaw to an embedded i386 computer via an RS-232 
link from its own processor based control box. Two 
i486 based computers deliver video with text or 
graphics overlay to the monitors. The headphones 
are driven by a third i486 computer which handles 
speech synthesis and other audio feedback 
functions. This computer also handles voice 
recognition tasks, making use of the microphone. All 
three computers use ISA to VME bus adaptors to 
communicate with the VMEbus. Video and audio 
signals from a remote robot are currently transmitted 
through dedicated channels. 

A chair platform includes control pedals and a 
transmitter for the HMD position sensor. 
Potentiometers in the pedals are powered and read by 
the same hardware used with the exoskeletons. 
Signals are also processed by the embedded i386 
computer and results are available on the VMEbus. 
The HMD position sensor transmitter has its own 
power supply and processor based control box. 

An i486 embedded in the VMEbus serves as the 
command and control computer of TRIP. Through the 
VMEbus, this computer can communicate with all 
subsystems and coordinate their interactions. In 
addition, this computer handles all data 
communications with remote robots through an 
ethernet network board and a single dedicated cable. 


3.3 Software Architecture 

Figure 3.3.1 displays the current high level software 
architecture. Software modules are shown in round- 
edge rectangles, and hardware is represented in 
square-edge rectangles. 

The software architecture consists of control and 
configuration tasks, command routers, command 
handlers, bus data exchange drivers, RS-232 
interface drivers, and TCP/IP network interface 
drivers. 

The control and configuration tasks reside on an 
embedded i486 computer in the VMEbus. These allow 
the operator to calibrate subsystems and define 
subsystem interaction rules. Control tasks 
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coordinate the interactions between various 
subsystems. 

Command routers serve two functions. First, 
process data from input devices to produce specific 
subsystem commands. Second, route these 
commands to the appropriate subsystem message 
areas. Command routers are used with the voice 
recognition system and all motion input devices. 

Command handlers accept commands or messages 
from command routers and execute the commands or 
answer messages. Command handlers are used with 
output systems such as video and graphic overlays, 
speech synthesis, and environmental audio. 

Bus data exchange drivers allow commands and 
messages to be physically exchanged between the 
ISA buses and the VMEbus. Both embedded and 
external computers use these drivers 

Drivers for the RS-232 ports are used by the 
embedded i386 computer to communicate with the 
HMD position sensor controller. Commands can be 
sent to the controller and raw orientation data is read. 
This raw data is also parsed and made available to 
bus data exchange drivers. 

Network access is provided by interface drivers using 
the TCP/IP protocols. These are used by the 
communication subsystem to transmit commands to 
or receive messages from a remote robot. They are 
also used to handle commands from TRIP 
subsystems and route commands from the robot to 
appropriate handlers. 



3.4 Software Toole 

Current software tools comprise two operating 
systems and three compilers. Windows 3.1 and iRMX 
are the operating systems and they support 
development with Visual Basic, Borland C++, and 
iRMX C. 

Windows 3.1 provides cooperative, event driven 
multitasking with an easy to use graphical human 
interface. A large number of board level drivers 
directly support this operating system and 
development with its standard user interface. 
Windows 3.1 also provides a growth path to a 32 bit 
preemptive multitasking/multiprocessing environment 
with Windows NT. Windows NT will be backward 
compatible with 3.1 and will use the same graphical 
interface standards. It should be available at the end 
of 1992. 

iRMX provides 32 bit mode operation of the Intel 
microprocessors and real time task scheduling for low 
level, time critical tasks. A unique feature of this 
operating system is its ability to run Windows as a 
task and communicate between the two operating 
systems. This enables the best of two worlds: 32 bit 
hard real time tasking and an easy to use standard 
interface. 

Visual Basic (VB) is an object oriented visual 
development environment for the Windows operating 
system. Objects can send or receive messages, and 
events can be used to trigger user developed code or 
operating system calls. The syntax is similar to that 
of Basic, but the code structure and object orientation 
endow it with many features found in C++. The visual 
development environment lends itself to very rapid 
prototyping of code and almost effortless user 
interface development. VB does not support some of 
the low level capabilities found in C or C++, but 
Dynamic Link Library (DLL) functions written in C or 
C++ may easily be called. Operating system 
functions may also be called directly from VB. 
Dynamic Data Exchange (DDE), a client/server 
intertask communication protocol, is also supported 
and easy to use. 

Borland C++ is an object oriented C development 
environment which supports development for the 
Windows operating system. Specific to this project, it 
allows the development of low level DLL functions 
which may be called from VB code. Borland supplies 
an efficient code development environment with 
extensive debugging support. The object orientation 
promotes development of complete code modules 
which e a easy to reuse and build upon. 

iRMX C is a compiler and assorted tools for 
developing C code task modules which run in the 
iRMX real time operating system. These modules will 
accommodate time critical, low level functions as 
required by the TRIP. These functions may 
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communicate with Windows hosted code to report 
system status, alarms, or data needs. 

3.5 Floor Layout 

A planform view of TRIP hardware is displayed in 
figure 3.5.1. Shown are the chair platform, a 19 inch 
equipment rack, and two development work sites. An 
adjustable chair is mounted to the platform and 
serves as the operator work site. Pedals, 
exoskeletons, and the HMD are all connected from 
the chair platform to equipment in the 19 inch rack. 
The rack contains all TRIP computers along with audio 
and video ancillary equipment. Two development 
work sites each incorporate a keyboard, mouse, and 
two SVGA monitors. One work site supports 
development on VMEbus subsystems which include 
command and control, communication, and motion. 
The other work site supports development on the 
audio and video subsystems. 



Figure 3.5. 1 - Floor Layout 

4.0 SUBSYSTEM DETAILS 

4.1 Motion Subsystem 

The motion subsystem generates commands to 
control position or rate of all articulated members on a 
remote robot. Robot members include arms, hands, 
torso's, camera platforms, and mobile bases. The 
operator controls these using a combination of 
exoskeletons, foot pedals, and position sensors. 
Force reflection and tactile feedback for the operator 
are planned as growth paths in the arm and hand 
exoskeletons of this subsystem. 

Current components of this subsystem are detailed in 
figure 4.1.1. It consists of an embedded i386 
computer, an HMD position sensor, an A/D board with 
a signal conditioning box, exoskeleton arm and hand 
masters, and foot pedals. 

An embedded i386 based computer from the Radisys 
Corporation is used for subsystem processing and 
control. It runs at a clock speed of 25 MHz, contains 
8 MB of DRAM, a keyboard controller, serial ports, 
and an ISA compatible private bus which supports a 


40 MB hard disk and a super VGA controller board. It 
boots with a PC/AT compatible BIOS ROM and 
supports a number of operating systems. Radisys 
also supplies low level functions which allow direct 
access to all VMEbus memory spaces. These 
functions are compatible with TRIP software tools. 

A Logitech 6D Mouse is used to sense the HMD 
position and orientation. It makes use of an 
ultrasonic transmitter and receiver triangles to 
determine location in Cartesian space (x, y, z) and 
orientation (roll, pitch, yaw) as Euler angles or 
quaternions. Also included is a dedicated control 
processor which communicates with the host 
processor via RS-232. Advantages of ultrasonics 
over magnetic sensors include reduced lag times and 
no interference from metal structures. A 
disadvantage is that the full range (0-360 degrees) of 
Euler angles is not supported, although TRIP does not 
require the full range for HMD tracking. 



Figure 4.1.1 - Motion Subsy stem Block Diagram 


A VMIVME 3118 scanning A/D board is used in 
conjunction with a signal conditioning board 
developed in-house to support 64 differential 
channels. The A/D board interfaces to the VMEbus 
via control registers and a dual ported RAM data 
buffer. The signal conditioning board is housed in a 
separate box with a dedicated power supply. The 
board low pass filters (10 Hz) each channel and 
buffers the signal lines to the A/D board. It also 
supplies power to sensors on the exoskeletons and 
foot pedals. 

Two exoskeleton arm masters (EAM) and two 
dexterous hand masters (DHM) from Exos, Inc. are 
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utilized in TRIP. The EAM provides precise 
measurements of human shoulder and elbow joint 
angles. Potentiometers are currently used to sense 
the angles. The DHM uses hall effect sensors to 
measure joint angles of the human hand. A 
GripMaster (GM) is integrated into each DHM to 
measure wrist motion. Development continues to be 
funded by NASA with future objectives including the 
addition of sensory feedback in all areas. The current 
TRIP design will be capable of integrating these 
planned improvements. 

Foot pedals can be used to control robot torso and/or 
mobile base motion. In both cases, potentiometers 
are used to sense ankle joint angles which provide 
rate and directional control of robot motors. These 
pedals are attached to the chair platform. 

Software tasks running on the i386 read and process 
raw data from each of the input devices. One task 
reads a data buffer on the A/D board and processes 
for joint angle or rate commands. Processing 
includes some simple (i.e. boxcar) noise filtering and 
any required coordinate transforms. The A/D board 
continuously scans all active channels and updates 
the entire data buffer at about 800 Hz. A second task 
on the i386 reads and parses data from an RS-232 
port to determine roll, pitch, and yaw of the HMD. This 
port communicates with the position sensor controller 
which continuously updates position readings at 
about 50 Hz. A third task on i386 accepts processed 
data from the other tasks and routes it to the 
appropriate command handlers (i.e., communication , 
graphic overlay, etc.) using bus data exchange 
drivers. 

4.2 Video Subsystem 

A video subsystem handles all live video signals 
along with any computer generated graphics. Video is 
supplied by camera pairs on the remote robot which 
are designed to provide stereo video to the human 
eyes. Computer generated graphics and/or text may 
be calibrated to the video and overlayed to provide 
visual feedback, simulation results, or task tools to 
the operator. 

Figure 4.2.1 is a diagram showing half of the video 
subsystem. Each half feeds one of the operators 
eyes, and both halves are identical. Components 
include a helmet with HMD's, a video scan converter, 
a frame grabber and video compression board, an 
SVGA graphics board, an i486 based ISA bus 
computer, and ISA to VMEbus adaptor boards. 

A head mounted display helmet from Virtual Research 
is currently in house. It incorporates headphones, 
the Logitech 6-D Mouse receiver triangle, two color 
LCD displays (360 x 240 pixels), and wide angle 
optics from Leep Systems. The helmet is designed 
for comfort is extremely easy to don and doff. The 
Leep Systems optics have become an industry 
standard and can provide a field-of-view in excess of 
1 00°. Currently available LCD displays do not have 


the resolution required to support the detailed video or 
graphics ultimately desired in TRIP. In response, 
work is progressing in-house to develop higher 
resolution black and white HMD's which make use of 
wide angle optics and flat panel CRT's. Other 
concepts for increased resolution and color are under 
consideration. 

The Genie scan converter from Jovian will accept 60 
Hz non-interlaced RGB signals (i.e. VGA at 640 x 
480) as input and produce a 30 Hz interlaced NTSC 
signal as output. Monitors in most head mounted 
displays currently require an NTSC signal. In 
addition, the scan converter provides a gain 
adjustment and flicker filtering. Without the flicker 
filtering , certain horizontal lines appear to flicker and 
may contribute excessively to operator fatigue. 



Figure 4.2.1 - Video Subsys tem Block Diagram 


The frame grabber and video compression boards are 
supplied by New Media Graphics and both include low 
level software drivers which are compatible with TRIP 
software tools. The frame grabber digitizes and scan 
converts live video from external cameras, allowing 
software manipulation of the images. In addition, this 
board will genlock and overlay (via graphics color 
keying) VGA signals using a dedicated video (VESA) 
bus. The video compression board enables 
compression and decompression of full motion (30 
Hz) video using a C-Cube CL550 JPEG chip. It 
supports storage, playback, and network 
transmission of video signals using a private video 
bus with the frame grabber. 
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An Orchid Fahrenheit 1280° graphics accelerator was 
selected as the VGA board. It provides complete 
Super VGA functionality and makes use of a 
dedicated on-board processor to support graphics 
intensive applications. Low level drivers are included 
for the Windows operating system. 

Two i486 based computers are used for subsystem 
control functions and as graphics engines. Each runs 
at a dock speed of 33 MHz, contains 8 MB of DRAM, 
a keyboard controller, serial ports, and an ISA bus 
which supports a 210 MB hard disk and subsystem 
video boards. They boot with a PC/AT compatible 
BIOS ROM and support all TRIP operating systems. 

Bus adaptors are supplied by Bit3 Corporation and 
provide a high bandwidth link between the VMEbus 
and ISA bus. Boards in each bus are linked with a 
shielded, mutticonductor cable. The VMEbus board 
contains 2 MB of dual ported RAM which maps into the 
memory space of both buses. 

This subsystem accepts commands and messages 
from the VMEbus through the bus adaptors. Software 
tasks running on the i486 computers are used to 
control the display of live video and to generate 
desired graphics or text overlays. Graphics can 
include wireframe models driven by simulations and 
text may include voice menu selections or data from 
the remote robot. The video, graphics, and/or text are 
merged in the frame grabber and fed to the scan 
converter. This converter produces a filtered 30 Hz 
interlaced NTSC signal which the HMD directly 
accepts and displays to the operator. Future HMD's 
with higher resolutions may directly accept the 60 Hz 
non-interlaced RGB signals, allowing scan converters 
to be bypassed. 


4.3 Audio Subsystem 

Speech synthesis, environmental audio, and voice 
recognition are all part of the audio subsystem. 
Speech synthesis provides TRIP an additional path 
for relaying data or messages to the operator. 
Environmental audio can be used to supply cues or 
feedback on the remote environment. This can take 
the form of actual environmental sounds (where 
possible) and/or computer generated sounds which 
cue the operator. Voice recognition essentially 
replaces the keyboard as an operator input device 
and is required when the operator is wearing 
exoskeletons. 

Figure 4.3.1 diagrams the audio subsystem. 
Components include helmet mounted headphones 
and microphone, a voice recognition system board, a 
speech synthesis board, an audio mixing system with 
an interface board, an i486 based ISA bus computer, 
and ISA to VMEbus adaptor boards. 

The headphones and a microphone are part of the 
helmet assembly. Headphones are driven by an audio 


mixing system and the microphone supplies audio 
signals to a voice recognition system. 

The voice recognition system was developed by 
Speech Systems Incorporated. It provides 
continuous speech recognition which is speaker 
independent and includes a large vocabulary 
dictionary (about 40,000 words) which can be 
amended by the developer. A unique combination of 
speech encoding, acoustic frame compression, and 
linguistic decoding is used to support large, variable 
duration segments. 



Figure 4.3.1 - Audio Subsystem Blo ck Diagram 

Speech synthesis is provided by the DoubleTalk PC 
board and drivers from RC Systems. The board uses 
its own 10 MHz, 16 bit microprocessor and supports 
multiple speech technologies such as text-to-speech, 
LPC, PCM, ADPCM, and CVSD. The analog output 
can directly drive headphones or be directed through 
a mixing system. 

Audio switching, mixing, and signal processing is 
accommodated with a CDPC multimedia system by 
Media Vision. The system is based on the electronics 
of their Pro AudioSpectrum 16 and includes multiple 
audio input and output signal options. Signal 
processing includes digital filtering, tone control, 
bass enhancement, and signal equalization. The 
analog mixer supports volume control of each source, 
fade in/out, and audio panning. The system includes 
an ISA bus interface board and low level drivers which 
are compatible with TRIP software tools. 
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An i486 based computer is used for subsystem 
processing and control. It runs at a clock speed of 33 
MHz, contains 8 MB of DRAM, a keyboard controller, 
serial ports, and an ISA bus which supports a 210 MB 
hard disk and subsystem audio boards. It boots with 
a PC/AT compatible BIOS ROM and supports all TRIP 
operating systems. 

A Bit3 bus adaptor provides a high bandwidth link 
between the VMEbus and this subsystem. Boards in 
each bus are linked with a shielded, multiconductor 
cable. The VMEbus board contains 2 MB of dual 
ported RAM which maps into the memory space of 
both buses. 

The audio subsystem exchanges commands and 
messages with the VMEbus through its bus adaptor. 
Software tasks running on the i486 computer handle 
commands for speech synthesis and environmental 
audio functions. Synthetic speech and environmental 
audio signals are processed and mixed by the CDPC 
system, then fed to headphones in the helmet. The 
operators voice is picked up by the microphone and 
fed to the voice recognition system for interpretation. 
Resulting commands are routed to the message areas 
of appropriate subsystems. 


4.4 Communication Subsystem 

The communication subsystem provides full duplex 
data transfers between TRIP and the remote robot 
using an ethernet based network. Data can represent 
commands, sensory information, event messages, or 
requests for information. 

Hardware for this subsystem is shown in figure 4.4.1. 
It basically consists of an embedded i486 computer 
from Radisys and an ethernet communications board. 

The i486 runs at a clock speed of 33 MHz, contains 8 
MB of DRAM, a keyboard controller, serial ports, and 
an ISA compatible private bus which supports a 210 
MB hard disk and a super VGA controller board. It is 
operationally similar to the i386 controller of the 
motion subsystem and uses the same low level 
drivers for VMEbus memory accesses. 

The ethernet board is Western Digital (8003EB) 
compatible and uses commonly available packet 
drivers. It also supports both thin and thick ethernet 
cables along with TCP/IP socket libraries. 

Software tasks running on the i486 computer serve 
three functions: (1) transfer data packets to and from 
the remote robot, (2) parse data packets and route 
information to other TRIP subsystems, and (3) handle 
commands from TRIP subsystems and build data 
packets. The data packets consists of structures 
which organize messages, commands, and 
information into a form which TRIP and the remote 
robot can both understand and easily parse. Future 
plans include incorporation of TelRIP software 
developed at Rice University. TelRIP (TeleRobotic 


Interconnection Protocol) is a layer built on top of 
TCP/IP with characteristics specific to teleoperation 
of robots. Other software tasks running on the i486 
route messages to other TRIP subsystems. 



Figure 4.4.1 - Communication & Command/Contffil 
Subsystem Block Diagram 


4.5 Command & Control Subsystem 

The command and control subsystem coordinates 
interactions of all subsystems with one another. It 
also serves as the focal point for system 
configuration and subsystem calibration efforts. 

This subsystem primarily consists of software, but 
shares the embedded i486 used by the 
communication subsystem shown in figure 4.4.1. 

Software running on the i486 computer provides 
system level arbitration of subsystem task and data 
interactions. These interactions may be defined in 
terms of the active communication paths between 
subsystems and the messages or commands 
understood on those paths. In addition, each of the 
other subsystems may be calibrated or adjusted from 
here to correspond to systems on the remote robot. 
Examples of this include mapping of exoskeleton 
joints to robot joints, definition of joint limits, 
activation of video targeting functions, and selection 
of environmental audio convolution methods. 


5.0 CLOSURE 

The project described in this paper is primarily a 
system integration effort. Architectures and 
approaches discussed are driven by a combination of 
operational needs, available technologies, and 
flexibility to incorporate projected technologies. 
Design goals included ease of use, configurational 
flexibility, and the inclusion of growth paths. These 
goals were constrained by cost and performance 
limits. 

5.1 Current Status 

All the basic hardware elements of TRIP are currently 
being integrated. Software tasks are either in the 
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detailed design or implementation phase of 
development. The DART anthropomorphic target 
robot is currently in the implementation phase and will 
be interfaced to TRIP by the end of this year. The 
AERCAM free-flying target robot is in the detailed 
design phase of development. 

5.2 Future Work 

Future work will address the implementation and 
testing of newly developed subsystem and 
programming technologies. Examples in the video 
area include higher resolution black & white monitors, 
direct VGA interfaces with wide angle optics, and 
computational graphics models as in reference 14. 
Motion control examples include the addition of 
force/torque reflection, haptic feedback, and 
teleprogramming concepts as described in reference 
25. TRIP will also make use of 3-D acoustics 
research and signal processing techniques, such as 
those of reference 1 9. Robot communications will be 
enhanced through updated versions of TelRIP 20 - 21 
software. Finally, an icon or block diagram based 
visual environment will be used for system 
configuration and subsystem calibrations. 
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